Policy consolidation for auto-orchestrated data centers

ABSTRACT

Techniques for generating and enforcing whitelist security policies in a communication network are disclosed. A first plurality of whitelist policies are consolidated into a second plurality of whitelist policies based on populating a plurality of tables. The populated tables include a first table including pairs of endpoints and associating each pair of endpoints with a service identifier, and a second table associating the service identifiers with the policy identifiers. The second plurality of whitelist policies are programmed into a network device in the communication network, based on at least one of the plurality of tables. Rules governing traffic between the pair of endpoints are enforced, at the network device, using the programmed second plurality of whitelist policies.

TECHNICAL FIELD

Embodiments presented in this disclosure generally relate to computernetworking. More specifically, though not exclusively, embodimentsdisclosed herein relate to policy consolidation for network datacenters.

BACKGROUND

Modern network data centers can include large numbers of networkpolicies. For example, data centers can include a very large number ofspecific security policies governing traffic within the data center. Insome circumstances, automated systems can be used to orchestrate dynamicgeneration of these security policies (and other network policies).

For example, data centers can include whitelist rules describing allowednetwork traffic within the data centers. But automated orchestrationsystems tend to create fine grained whitelist rules. These rules can befine-grained to the point that they define specific allowed networktraffic between specific network endpoints. The fine-grained nature ofthese automated policies can result in a huge number of whitelist ruleson a single network node or switch.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above-recited features of the presentdisclosure can be understood in detail, a more particular description ofthe disclosure, briefly summarized above, may be had by reference toembodiments, some of which are illustrated in the appended drawings. Itis to be noted, however, that the appended drawings illustrate typicalembodiments and are therefore not to be considered limiting, otherequally effective embodiments are contemplated.

FIG. 1 illustrates a network data center with auto-orchestration ofrules, according to one embodiment described herein.

FIG. 2 illustrates a leaf switch in a network data center withauto-orchestration of rules, according to one embodiment describedherein.

FIG. 3 is a flowchart illustrating consolidation of whitelist policiesfor a network data center with auto-orchestration of rules, according toone embodiment described herein.

FIG. 4 is a flowchart further illustrating consolidation of whitelistpolicies for a network data center with auto-orchestration of rules,according to one embodiment described herein.

FIG. 5 illustrates example whitelist policies for a network data centerprior to consolidation, according to one embodiment described herein.

FIGS. 6A-6O illustrate consolidation of the whitelist policies for anetwork data center illustrated in FIG. 5, according to one embodimentdescribed herein.

FIG. 7 is a flowchart illustrating programming consolidated whitelistrules in a leaf switch, according to one embodiment described herein.

FIG. 8 illustrates programming consolidated whitelist rules in a leafswitch, according to one embodiment described herein.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures. It is contemplated that elements disclosed in oneembodiment may be beneficially used in other embodiments withoutspecific recitation.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

Embodiments described herein include a computerized method forgenerating whitelist policies in a communication network. The methodincludes identifying a first plurality of whitelist policies for thecommunication network, each whitelist policy including a pair ofendpoints and a policy identifier identifying a rule governing trafficbetween the pair of endpoints. The method further includes consolidatingthe first plurality of whitelist policies into a second plurality ofwhitelist policies based on populating a plurality of tables using thefirst plurality of whitelist policies. The populated tables include afirst table including the pairs of endpoints and associating each pairof endpoints with a service identifier and a second table associatingthe service identifiers with the policy identifiers. The method furtherincludes programming the second plurality of whitelist policies into anetwork device in the communication network, based on at least one ofthe plurality of tables. The method further includes enforcing the rulesgoverning traffic between the pair of endpoints, at the network device,using the programmed second plurality of whitelist policies.

Embodiments described herein further include a system, including aprocessor and a memory containing computer program code that, whenexecuted by the processor, performs an operation. The operation includesidentifying a first plurality of whitelist policies for thecommunication network, each whitelist policy including a pair ofendpoints and a policy identifier identifying a rule governing trafficbetween the pair of endpoints. The operation further includesconsolidating the first plurality of whitelist policies into a secondplurality of whitelist policies based on populating a plurality oftables using the first plurality of whitelist policies. The populatedtables include a first table including the pairs of endpoints andassociating each pair of endpoints with a service identifier and asecond table associating the service identifiers with the policyidentifiers. The operation further includes programming the secondplurality of whitelist policies into a network device in thecommunication network, based on at least one of the plurality of tables.The operation further includes enforcing the rules governing trafficbetween the pair of endpoints, at the network device, using theprogrammed second plurality of whitelist policies.

Embodiments described herein further include a non-transitorycomputer-readable medium containing computer program code that, whenexecuted by operation of one or more computer processors, performs anoperation. The operation includes identifying a first plurality ofwhitelist policies for the communication network, each whitelist policyincluding a pair of endpoints and a policy identifier identifying a rulegoverning traffic between the pair of endpoints. The operation furtherincludes consolidating the first plurality of whitelist policies into asecond plurality of whitelist policies based on populating a pluralityof tables using the first plurality of whitelist policies. The populatedtables include a first table including the pairs of endpoints andassociating each pair of endpoints with a service identifier and asecond table associating the service identifiers with the policyidentifiers. The operation further includes programming the secondplurality of whitelist policies into a network device in thecommunication network, based on at least one of the plurality of tables.The operation further includes enforcing the rules governing trafficbetween the pair of endpoints, at the network device, using theprogrammed second plurality of whitelist policies.

Example Embodiments

Large numbers of whitelist rules on network nodes in data centers canresult in wasted memory and compute time. This can result in too manyrules to fit on a given network node, or network delays from enforcingthe rules. One or more embodiments described herein relate to techniquesfor consolidating these rules by exploiting patterns inauto-orchestrated whitelist rules. This significantly reduces the numberof rules programmed into a given network node, freeing memory andreducing switching and routing times.

For example, in some data center deployments, a service offered by avirtual machine (VM) can be utilized by thousands of clients. This cantranslate to thousands of identical rules between different pairs ofendpoints (e.g., devices communicating using the data center network).According to one or more techniques disclosed herein, these identicalrules, which differ only on the source and destination endpoints, can beconsolidated into a single policy (or smaller collection of policies)that is identified by a service identifier. All endpoints using thespecified service, to which the policy applies, can then be classifiedwith the service identifier. The policy can be administered for theclients and endpoints using the service identifier.

In practice, this can result in up to an 80% reduction in the number ofpolicies. Further, applying one or more techniques disclosed herein thenumber of policies used to enforce the desired rules does not depend onthe number of consumers. Instead, it depends on the services and typesof flows in the network (e.g., the data center).

Further, if a client VM migrates from one device to another, theassociated entry can simply be removed from the service identifiermapping. In this way, the rules for a service are present on a device aslong as at least one client behind the device is using the service. Therules can be removed once all clients behind the device migrate away orstop using the service.

FIG. 1 illustrates a network data center system 100 withauto-orchestration of rules, according to one embodiment describedherein. For example, the network data center system 100 can implementsoftware defined networking (SDN) principles. In an embodiment, SDNallows for a centralized, programmable network, including one or moreSDN controllers. While the data center system 100 can implement SDNprinciples, other suitable networking techniques and paradigms may beused instead of, or in addition to, SDN.

In an embodiment, a data center 120 includes a number of endpoints102A-N. The data center 120 further includes a number of switches122A-N. In an embodiment, the switches 122A-N are leaf switches in aspine-and-leaf architecture (e.g., in an SDN system). Alternatively, theswitches 122A-N can be any suitable network switches or other routingdevices in the data center 120. In an embodiment the switches 122A-N areprogrammable, and route traffic between the endpoints 102A-C in the datacenter 120. For example, an endpoint 102A can communicate with anendpoint 102B in the data center 120 using one or more of the switches122A-N. The data center 120 can use any suitable network communicationtechnique, including wired connections, wireless connections, cellularconnections, and any other suitable technique. Further, the data center120 can include any suitable network, including one or more local areanetworks (LANs), virtual local area networks (VLANs), or other suitablenetworks.

As another alternative, the switches 122A-N can be virtual switches(e.g., software or firmware applications operating to switch networktraffic). For example, the switches 122A-N can be virtual switchesoperating in a private cloud environment. As another alternative, theswitches 122A-N can be virtual switches operating in a public cloudenvironment.

As illustrated in FIG. 1, the data center 120 further includes anorchestration server 110. In an embodiment, the orchestration server 110provides data security and workload protection for the data center 120through analytics of network traffic within the data center 120. Forexample, the orchestration server 110 can operate with the data center120 to automatically generate whitelist security rules governing trafficwithin the data center. These rules can be programmed in one or more ofthe switches 122A-N to enforce the rules on network traffic. Whileembodiments disclosed herein are focused on whitelist security rules,the disclosed techniques are also suitable for other types of securityrules and policies, and for non-security related rules and policies.

In an embodiment, the system 100 further includes a public cloud 130.The data center 120 can further communicate with the public cloud 130(e.g., through one or more of the endpoints 102A-N).

FIG. 2 illustrates a switch in a network data center withauto-orchestration of rules, according to one embodiment describedherein. In an embodiment, the switch 122 in FIG. 2 corresponds with oneof the switches 122A-N illustrated in FIG. 1. As discussed above, in anembodiment the switch 122 is a programmable leaf switch in a leaf-spinearchitecture. The switch 122 includes a processor 202, a memory 210,network components 220, and rule enforcement components 230. Theprocessor 202 generally retrieves and executes programming instructionsstored in the memory 210. The processor 202 is included to berepresentative of a single central processing unit (CPU), multiple CPUs,a single CPU having multiple processing cores, graphics processing units(GPUs) having multiple execution paths, and the like. Alternatively,while in one embodiment the switch 122 is a hardware switch, asdiscussed above in another embodiment the switch 122 is a virtualswitch.

The network components 220 include the components necessary for theswitch 122 to interface with a communication network (e.g., in the datacenter 120 illustrated in FIG. 1). For example, the network components220 can include network interface components and associated software.Although the memory 210 is shown as a single entity, the memory 210 mayinclude one or more memory devices having blocks of memory associatedwith physical addresses, such as random access memory (RAM), read onlymemory (ROM), flash memory or other types of volatile and/ornon-volatile memory. In an embodiment, the memory 210 can include all,or a portion, ternary content-addressable memory (TCAM).

The memory 210 generally includes program code for performing variousfunctions related to use of the switch 122. The program code isgenerally described as various functional “applications” or “modules”within the memory 210, although alternate implementations may havedifferent functions and/or combinations of functions. Within the memory210, the policy consolidator module 212 consolidates policies (e.g.,whitelist policies), as described in relation to FIGS. 3-7 The switch122 further includes rule enforcement components 230. In an embodiment,the rule enforcement components 230 include hardware components toenforce policy rules on network traffic flowing through the switch 122.For example, the rule enforcement components 230 can includeprogrammable memory (e.g., TCAM) into which the rules can be programmed.

FIG. 3 is a flowchart illustrating consolidation of whitelist policiesfor a network data center with auto-orchestration of rules, according toone embodiment described herein. At block 302 a switch (e.g., the switch122 illustrated in FIG. 2) receives the initial collection of rules andendpoints. In an embodiment, this collection identifies the sourceendpoint, the destination endpoint, and the policy to apply for thatpairing. For example, collection 500 illustrated in FIG. 5 is oneexample of a collection of initial rules and endpoints. This format,however, is merely one example of a collection of rules and endpoints.Any suitable format can be used. Further, while FIG. 3 is discussed inthe context of using a switch for policy consolidation, in alternativeembodiments other hardware and software components (e.g., other networkdevices or servers) can be used.

At block 304, a policy consolidator (e.g., the policy consolidator 212illustrated in FIG. 2) creates tables for use in policy consolidation.In an embodiment, the policy consolidator creates three tables insoftware. A first software table identifying source and destinationpairs with a service identifier (e.g., the table 602 illustrated inFIGS. 6A-O), a second software table identifying different policies withidentifiers (e.g., the table 604 illustrated in FIGS. 6A-O), and a thirdsoftware table identifying different policy combinations for differentendpoint pairs (e.g., the table 606 illustrated in FIGS. 6A-O).

At block 306, the policy consolidator populates the tables using thecollection of rules and endpoints. This is discussed further with regardto FIGS. 4-6. At block 308, the policy consolidator programs the switchhardware (e.g., the rule enforcement components 230 illustrated in FIG.2) with rules using the populated tables. This is discussed further withregard to FIGS. 7-8. While this block is discussed in terms of hardwareenforcement, as discussed above in an embodiment the rules areprogrammed into memory for use by software (e.g., in a virtual switch).

FIG. 4 is a flowchart further illustrating consolidation of whitelistpolicies for a network data center with auto-orchestration of rules,according to one embodiment described herein. FIG. 5 illustrates examplewhitelist policies 500 for a network data center prior to consolidation,according to one embodiment described herein. FIGS. 6A-6O illustrateconsolidation of the whitelist policies for a network data centerillustrated in FIG. 5, according to one embodiment described herein.FIGS. 4-6 will be discussed together.

In an embodiment, FIG. 4 illustrates an example flowchart used forconsolidation of the whitelist rules illustrated in FIG. 5. For example,FIG. 5 includes 15 flows, each of which identifies a source endpoint, adestination endpoint, and a policy identifier identifying a rule toapply to traffic from the source endpoint to the destination endpoint.In an embodiment, each policy identifier identifies a rule for governingtraffic between the endpoints (e.g., a rule stored elsewhere andidentified using the policy identifier). Any suitable rule can be used,including rules relating to protocols, source ports, destination ports,differentiated services code point (DSCP), flags, directions, actions,etc.

Without consolidation, all fifteen of these flows would be programmedinto the rule enforcement components (e.g., the rule enforcementcomponents 230 of the switch 122 illustrated in FIG. 2). Instead, theflows are consolidated into 7 entries for programming into the ruleenforcement component. FIGS. 6A-O illustrate populating tables with thewhitelist rules illustrated in FIG. 5, as the flowchart illustrated inFIG. 4 progresses.

At block 402, a policy consolidator (e.g., policy consolidator 212illustrated in FIG. 2) selects the next flow. For example, asillustrated in FIG. 6A, the policy consolidator selects Flow-1, withendpoints EP1 and EP2 and policy identifier Policy1. At block 404, thepolicy consolidator determines whether the endpoints in the selectedflow are already in Table_1. In an embodiment, Table_1 in FIG. 4corresponds with the table 602 illustrated in FIGS. 6A-O, Table_2 inFIG. 4 corresponds with the table 604 illustrated in FIGS. 6A-O, andTable_3 in FIG. 4 corresponds with the table 606 illustrated in FIGS.6A-O.

As illustrated in FIG. 6A, the tables 602, 604, and 606 are initiallyempty. Therefore, at block 404, the policy consolidator determines thatthe endpoints in Flow-1 are not in the table 602. The flowchart thenproceeds to block 406, and the endpoints from Flow-1 are added toTable_1. This is shown in FIG. 6A, where the endpoints EP1 and EP2 areadded to the table 602 with a service ID 1.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6A). As illustrated in FIG. 6A, the table 604 is initially empty. Thus,the flowchart proceeds to block 412 and adds the policy to Table_2. Inthe example of FIG. 6A, the policy consolidator adds the policy Policy1to the table 604, with a reference count of 1. In an embodiment, thepolicy identifier Policy1 is assigned to this policy prior to policyconsolidation (e.g., during rule creation or at another suitable time).Alternatively, the policy identifier Policy1 can be assigned, orchanged, during consolidation.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The table 606 in FIG. 6A is initiallyempty, so the flowchart proceeds to block 418 and the policyconsolidator adds the policy combination to Table_3. In the example ofFIG. 6A, the policy consolidator adds the policy combination Policy1(e.g., Policy1 alone) to the table 606 in a row with service ID 1 andendpoints (EP1-EP2).

At block 422, the policy consolidator updates the service ID associatedwith the endpoints in the table 602, if necessary, based on the serviceID used in the table 606. At block 424, the policy consolidatordetermines whether this is the last flow in the list of whitelistpolicies. It is not, so the flowchart returns to block 402 and selectsthe next flow.

This is illustrated in FIG. 6B: Flow-2, with source endpoint EP1,destination endpoint EP3, and policy identifier Policy2. At block 404,the policy consolidator determines that the endpoints in Flow-2 (e.g.,EP1-EP3) are not in the table 602. The flowchart proceeds to block 406,and adds these endpoints to the table 602, as illustrated in FIG. 6B.This row is assigned the service ID 2.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6B). As illustrated in FIG. 6B, policy2 is not in the table 604. Theflowchart proceeds to block 412 and the policy consolidator adds policy2to the table 604.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. Policy2 is not in the table 606, sothe flowchart proceeds to block 418 and adds the policy combination toTable_3. In the example of FIG. 6B, the policy consolidator adds thepolicy combination Policy2 (e.g., Policy2 alone) to the table 606 in arow with service ID 2 and endpoints (EP1-EP3). At block 422, the policyconsolidator updates the service ID associated with the endpoints in thetable 602, if necessary, based on the service ID used in the table 606.Flow-2 is again not the last flow, so the policy consolidator returns toblock 402 and selects the next flow.

FIG. 6C illustrates this next flow: Flow-3, with source endpoint EP4,destination endpoint EP5, and policy identifier Policy1. At block 404,the policy consolidator determines that the endpoints in Flow-3 (e.g.,EP4-EP5) are not in the table 602. The flowchart proceeds to block 406,and adds these endpoints to the table 602, as illustrated in FIG. 6C.This endpoint combination is associated with policy1, so the endpointsEP4-EP5 are assigned the service ID already associated with policy1 inthe table 606: service ID 1.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6C). As illustrated in FIG. 6C, policy1 is in the table 604, so theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the reference count for policy1 from 1 to 2.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. Policy1 is in the table 606, so theflowchart proceeds to block 420. At block 420, the policy consolidatorupdates the row associated with policy1 (and service ID 1) to includethe endpoints (EP4-EP5). At block 422, the policy consolidator updatesthe service ID associated with the endpoints in the table 602, ifnecessary, based on the service ID used in the table 606. Flow-3 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6D illustrates this next flow: Flow-4, with source endpoint EP6,destination endpoint EP7, and policy identifier Policy2. At block 404,the policy consolidator determines that the endpoints in Flow-4 (e.g.,EP6-EP7) are not in the table 602. The flowchart proceeds to block 406,and adds these endpoints to the table 602, as illustrated in FIG. 6D.This endpoint combination is associated with policy2, so the endpointsEP6-EP7 are assigned the service ID already associated with policy2 inthe table 606: service ID 2.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6D). As illustrated in FIG. 6D, policy2 is in the table 604, so theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the reference count for policy2 from 1 to 2.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. Policy2 is in the table 606, so theflowchart proceeds to block 420. At block 420, the policy consolidatorupdates the row associated with policy2 (and service ID 2) to includethe endpoints (EP6-EP7). At block 422, the policy consolidator updatesthe service ID associated with the endpoints in the table 602, ifnecessary, based on the service ID used in the table 606. Flow-4 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6E illustrates this next flow: Flow-5, with source endpoint EP8,destination endpoint EP9, and policy identifier Policy1. At block 404,the policy consolidator determines that the endpoints in Flow-5 (e.g.,EP8-EP9) are not in the table 602. The flowchart proceeds to block 406,and adds these endpoints to the table 602, as illustrated in FIG. 6E.This endpoint combination is associated with policy1, so the endpointsEP8-EP9 are assigned the service ID already associated with policy1 inthe table 606: service ID 1.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6E). As illustrated in FIG. 6E, policy1 is in the table 604, so theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the reference count for policy1 from 2 to 3.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. Policy1 is in the table 606, so theflowchart proceeds to block 420. At block 420, the policy consolidatorupdates the row associated with policy1 (and service ID 1) to includethe endpoints (EP8-EP9). At block 422, the policy consolidator updatesthe service ID associated with the endpoints in the table 602, ifnecessary, based on the service ID used in the table 606. Flow-5 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6F illustrates this next flow: Flow-6, with source endpoint EP10,destination endpoint EP2, and policy identifier Policy4. At block 404,the policy consolidator determines that the endpoints in Flow-6 (e.g.,EP10-EP2) are not in the table 602. The flowchart proceeds to block 406,and adds these endpoints to the table 602, as illustrated in FIG. 6F.These endpoints are assigned service ID 3 because policy4 has not yetbeen added to the table 606.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6F). As illustrated in FIG. 6F, policy4 is not in the table 604, so theflowchart proceeds to block 412. At block 412, the policy consolidatoradd policy4 to the table 604, with a reference count of 1.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. Policy4 is not in the table 606, sothe flowchart proceeds to block 418. At block 418, the policyconsolidator adds a row with service ID 3, policy4, and endpoints(EP10-EP2) to the table 606. At block 422, the policy consolidatorupdates the service ID associated with the endpoints in the table 602,if necessary, based on the service ID used in the table 606. Flow-6 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6G illustrates this next flow: Flow-7, with source endpoint EP1,destination endpoint EP2, and policy identifier Policy4. At block 404,the policy consolidator determines that the endpoints in Flow-7 (e.g.,EP1-EP2) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6G). As illustrated in FIG. 6G, policy4 is in the table 604, so theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the reference count associated with policy4 from 1 to 2.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy1,policy4) is not in the table 606, so the flowchart proceeds to block418. At block 418, the policy consolidator adds a row with service ID 4,policy combination (policy1, policy4), and endpoints (EP1-EP2) to thetable 606. Of note, in an embodiment, each endpoint pairing isassociated with only one service ID and one policy combination. Endpointpair (EP1-EP2) is associated with both policy1 and policy4. So thepolicy consolidator removes endpoints (EP1-EP2) from the row in thetable 606 associated with just policy1 (and service ID 1) when it addsendpoints (EP1-EP2) to the row associated with both policy1 and policy4(and service ID 4). At block 422, the policy consolidator updates theservice ID associated with the endpoints in the table 602, if necessary,based on the service ID used in the table 606. Flow-7 is again not thelast flow, so the policy consolidator returns to block 402 and selectsthe next flow.

FIG. 6H illustrates this next flow: Flow-8, with source endpoint EP1,destination endpoint EP3, and policy identifier Policy5. At block 404,the policy consolidator determines that the endpoints in Flow-8 (e.g.,EP1-EP3) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6H). As illustrated in FIG. 6H, policy5 is not in the table 604. So theflowchart proceeds to block 412. At block 412, the policy consolidatoradds policy5 to the table 604 with a reference count of 1.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy2,policy5) is not in the table 606, so the flowchart proceeds to block418. At block 418, the policy consolidator adds a row with service ID 5,policy combination (policy2, policy5), and endpoints (EP1-EP3) to thetable 606. Endpoint pair (EP1-EP3) is associated with both policy2 andpolicy5. So the policy consolidator removes endpoints (EP1-EP3) from therow in the table 606 associated with just policy2 (and service ID 2)when it adds endpoints (EP1-EP3) to the row associated with both policy2and policy5 (and service ID 5). At block 422, the policy consolidatorupdates the service ID associated with the endpoints in the table 602,if necessary, based on the service ID used in the table 606. Flow-8 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6I illustrates this next flow: Flow-9, with source endpoint EP4,destination endpoint EP5, and policy identifier Policy4. At block 404,the policy consolidator determines that the endpoints in Flow-9 (e.g.,EP4-EP5) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6I). As illustrated in FIG. 6I, policy4 is in the table 604. So theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the row associated with policy4 to a reference count of 3.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy1,policy4) is in the table 606, so the flowchart proceeds to block 420. Atblock 420, the policy consolidator updates the row associated with(policy1, policy4), and service ID 4, to include the endpoints(EP4-EP5). Endpoint pair (EP4-EP5) is associated with both policy1 andpolicy4. So the policy consolidator removes endpoints (EP4-EP5) from therow in the table 606 associated with just policy1 (and service ID 1)when it adds endpoints (EP4-EP5) to the row associated with both policy1and policy4 (and service ID 4). At block 422, the policy consolidatorupdates the service ID associated with the endpoints in the table 602,if necessary, based on the service ID used in the table 606. Flow-9 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6J illustrates this next flow: Flow-10, with source endpoint EP6,destination endpoint EP7, and policy identifier Policy5. At block 404,the policy consolidator determines that the endpoints in Flow-10 (e.g.,EP6-EP7) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6J). As illustrated in FIG. 6J, policy5 is in the table 604. So theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the row associated with policy5 to a reference count of 2.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy2,policy5) is in the table 606, so the flowchart proceeds to block 420. Atblock 420, the policy consolidator updates the row associated with(policy2, policy5), and service ID 5, to include the endpoints(EP6-EP7). Endpoint pair (EP6-EP7) is associated with both policy2 andpolicy5. So the policy consolidator removes endpoints (EP6-EP2) from therow in the table 606 associated with just policy2 (and service ID 2)when it adds endpoints (EP6-EP7) to the row associated with both policy2and policy5 (and service ID 5). At block 422, the policy consolidatorupdates the service ID associated with the endpoints in the table 602,if necessary, based on the service ID used in the table 606. Flow-10 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6K illustrates this next flow: Flow-11, with source endpoint EP8,destination endpoint EP9, and policy identifier Policy6. At block 404,the policy consolidator determines that the endpoints in Flow-11 (e.g.,EP8-EP9) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6K). As illustrated in FIG. 6K, policy6 is not in the table 604. So theflowchart proceeds to block 412. At block 412, the policy consolidatoradds a row for policy6, and sets the reference count to 1.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy1,policy6) is not in the table 606, so the flowchart proceeds to block418. At block 418, the policy consolidator adds the policy combination(policy1, policy6) to the table 606. In an embodiment, as illustrated inFIG. 6K, the policy consolidator determines that policy1, alone, is intable 606 and associated with the endpoints (EP8-EP9) and service ID 1.Because endpoints (EP8-EP-9) are the only endpoints associated withpolicy1, alone, and these endpoints should now be associated with bothpolicy1 and policy6, the policy consolidator updates the row associatedwith service ID 1 to include the combination (policy1, policy6), insteadof policy1 alone (e.g., as illustrated in FIG. 6J, above). At block 422,the policy consolidator updates the service ID associated with theendpoints in the table 602, if necessary, based on the service ID usedin the table 606. Flow-11 is again not the last flow, so the policyconsolidator returns to block 402 and selects the next flow.

FIG. 6L illustrates this next flow: Flow-12, with source endpoint EP10,destination endpoint EP2, and policy identifier Policy6. At block 404,the policy consolidator determines that the endpoints in Flow-12 (e.g.,EP10-EP2) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6L). As illustrated in FIG. 6M, policy5 is in the table 604. So theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the row associated with policy6 to a reference count of 2.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy4,policy6) is not in the table 606, so the flowchart proceeds to block418. At block 418, the policy consolidator adds the policy combination(policy4, policy6) to the table 606. In an embodiment, as illustrated inFIG. 6L, the policy consolidator determines that policy4, alone, is intable 606 and associated with the endpoints (EP10-EP2) and service ID 3.Because endpoints (EP10-EP-2) are the only endpoints associated withpolicy4, alone, and these endpoints should now be associated with bothpolicy4 and policy6, the policy consolidator updates the row associatedwith service ID 3 to include the combination (policy4, policy6), insteadof policy4 alone (e.g., as illustrated in FIG. 6K, above). At block 422,the policy consolidator updates the service ID associated with theendpoints in the table 602, if necessary, based on the service ID usedin the table 606. Flow-12 is again not the last flow, so the policyconsolidator returns to block 402 and selects the next flow.

FIG. 6M illustrates this next flow: Flow-13, with source endpoint EP1,destination endpoint EP2, and policy identifier Policy6. At block 404,the policy consolidator determines that the endpoints in Flow-13 (e.g.,EP1-EP2) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6M). As illustrated in FIG. 6M, policy6 is in the table 604. So theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the row associated with policy6 to a reference count of 3.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy1,policy4, policy6) is not in the table 606, so the flowchart proceeds toblock 418. At block 418, the policy consolidator adds the policycombination (policy1, policy4, policy6) to the table 606, and associatesit with service ID 6. Endpoint pair (EP1-EP2) is associated with allthree of policy1, policy4, and policy6. So the policy consolidatorremoves endpoints (EP1-EP2) from the row in the table 606 associatedwith just policy1 and policy4 (and service ID 4) when it adds the newrow with service ID 6, policy combination (policy1, policy4, policy6)and endpoints (EP1-EP2). At block 422, the policy consolidator updatesthe service ID associated with the endpoints in the table 602, ifnecessary, based on the service ID used in the table 606. Flow-13 isagain not the last flow, so the policy consolidator returns to block 402and selects the next flow.

FIG. 6N illustrates this next flow: Flow-14, with source endpoint EP8,destination endpoint EP9, and policy identifier Policy4. At block 404,the policy consolidator determines that the endpoints in Flow-14 (e.g.,EP8-EP9) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6N). As illustrated in FIG. 6N, policy4 is in the table 604. So theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the row associated with policy4 to a reference count of 4.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy1,policy4, policy6) is in the table 606, so the flowchart proceeds toblock 420. At block 420, the policy consolidator updates the rowassociated with policy combination (policy1, policy4, policy) andservice ID 6 to includes endpoints (EP8-EP9). Endpoint pair (EP8-EP9) isassociated with all three of policy1, policy4, and policy6. So thepolicy consolidator removes endpoints (EP8-EP9) from the row in thetable 606 associated with just policy1 and policy6 (and service ID 1)when it adds the endpoints (EP8-EP9) to the row associated with serviceID 6 and policy combination (policy1, policy4, policy6). At block 422,the policy consolidator updates the service ID associated with theendpoints in the table 602, if necessary, based on the service ID usedin the table 606. Flow-14 is again not the last flow, so the policyconsolidator returns to block 402 and selects the next flow.

FIG. 6O illustrates this next flow: Flow-15, with source endpoint EP4,destination endpoint EP5, and policy identifier Policy6. At block 404,the policy consolidator determines that the endpoints in Flow-15 (e.g.,EP4-EP5) are in the table 602, so the flowchart proceeds to block 410.

At block 410, the policy consolidator determines whether the policyidentifier is already in Table_2 (e.g., table 604 illustrated in FIG.6O). As illustrated in FIG. 6O, policy6 is in the table 604. So theflowchart proceeds to block 414. At block 414, the policy consolidatorupdates the row associated with policy6 to a reference count of 3.

At block 416, the policy consolidator determines whether the policycombination is already in Table_3. The policy combination (policy1,policy4, policy6) is in the table 606, so the flowchart proceeds toblock 420. At block 420, the policy consolidator updates the rowassociated with policy combination (policy1, policy4, policy) andservice ID 6 to includes endpoints (EP4-EP5). Endpoint pair (EP4-EP5) isassociated with all three of policy1, policy4, and policy6. So thepolicy consolidator removes endpoints (EP4-EP5) from the row in thetable 606 associated with just policy1 and policy4 (and service ID 4)when it adds the endpoints (EP4-EP5) to the row associated with serviceID 6 and policy combination (policy1, policy4, policy6). At block 422,the policy consolidator updates the service ID associated with theendpoints in the table 602, if necessary, based on the service ID usedin the table 606. Flow-15 is, finally, the last flow so the flowchart inFIG. 4 ends.

FIG. 7 is a flowchart illustrating programming consolidated whitelistrules in a leaf switch, according to one embodiment described herein.FIG. 8 illustrates programming consolidated whitelist rules in a leafswitch, according to one embodiment described herein. These Figures willbe discussed together.

At block 702 a policy consolidator (e.g., policy consolidator 212illustrated in FIG. 2) generates rules tables for hardware. For example,as illustrated in FIG. 8, the policy consolidator generates table 802from tables 604 and 606. The table 802 includes a row for each policyand service ID combination included in tables 604 and 606. For example,service ID 3 is tied to policy4 and policy6. A flow associated withservice ID 3 should, therefore, implement both policy4 and policy6. Thetable 802 includes a row associating service ID 3 with policy4, and arow associating service ID 3 with policy6. Likewise, service ID 5 isassociated with policy2 and policy5. And service ID 6 is associated withpolicy1, policy4, and policy6.

At block 704, the policy consolidator programs the rules table in thehardware (e.g., into the rule enforcement components 230 in the switch122). In an embodiment, the policy consolidator programs table 602 andtable 802, as illustrated in FIG. 8, into the hardware. Using thesetables, the switch (e.g., the switch 122) can apply the appropriatepolicy for each endpoint combination. The switch can look-up a serviceID associated with the endpoint combination, using table 602, and canthen identify the policies associated with that service ID using thetable 802.

In the current disclosure, reference is made to various embodiments.However, the scope of the present disclosure is not limited to specificdescribed embodiments. Instead, any combination of the describedfeatures and elements, whether related to different embodiments or not,is contemplated to implement and practice contemplated embodiments.Additionally, when elements of the embodiments are described in the formof “at least one of A and B,” it will be understood that embodimentsincluding element A exclusively, including element B exclusively, andincluding element A and B are each contemplated. Furthermore, althoughsome embodiments disclosed herein may achieve advantages over otherpossible solutions or over the prior art, whether or not a particularadvantage is achieved by a given embodiment is not limiting of the scopeof the present disclosure. Thus, the aspects, features, embodiments andadvantages disclosed herein are merely illustrative and are notconsidered elements or limitations of the appended claims except whereexplicitly recited in a claim(s). Likewise, reference to “the invention”shall not be construed as a generalization of any inventive subjectmatter disclosed herein and shall not be considered to be an element orlimitation of the appended claims except where explicitly recited in aclaim(s).

As will be appreciated by one skilled in the art, the embodimentsdisclosed herein may be embodied as a system, method or computer programproduct. Accordingly, embodiments may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,embodiments may take the form of a computer program product embodied inone or more computer readable medium(s) having computer readable programcode embodied thereon.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for embodiments of thepresent disclosure may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present disclosure are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatuses(systems), and computer program products according to embodimentspresented in this disclosure. It will be understood that each block ofthe flowchart illustrations and/or block diagrams, and combinations ofblocks in the flowchart illustrations and/or block diagrams, can beimplemented by computer program instructions. These computer programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing thefunctions/acts specified in the block(s) of the flowchart illustrationsand/or block diagrams.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other device to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the block(s) of the flowchartillustrations and/or block diagrams.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other device to cause aseries of operational steps to be performed on the computer, otherprogrammable apparatus or other device to produce a computer implementedprocess such that the instructions which execute on the computer, otherprogrammable data processing apparatus, or other device provideprocesses for implementing the functions/acts specified in the block(s)of the flowchart illustrations and/or block diagrams.

The flowchart illustrations and block diagrams in the Figures illustratethe architecture, functionality, and operation of possibleimplementations of systems, methods, and computer program productsaccording to various embodiments. In this regard, each block in theflowchart illustrations or block diagrams may represent a module,segment, or portion of code, which comprises one or more executableinstructions for implementing the specified logical function(s). Itshould also be noted that, in some alternative implementations, thefunctions noted in the block may occur out of the order noted in theFigures. For example, two blocks shown in succession may, in fact, beexecuted substantially concurrently, or the blocks may sometimes beexecuted in the reverse order, depending upon the functionalityinvolved. It will also be noted that each block of the block diagramsand/or flowchart illustrations, and combinations of blocks in the blockdiagrams and/or flowchart illustrations, can be implemented by specialpurpose hardware-based systems that perform the specified functions oracts, or combinations of special purpose hardware and computerinstructions.

In view of the foregoing, the scope of the present disclosure isdetermined by the claims that follow.

We claim:
 1. A computerized method for generating whitelist policies ina communication network, comprising: identifying a first plurality ofwhitelist policies for the communication network, each whitelist policydescribing a security rule governing traffic between a pair of endpointsin the communication network and comprising the pair of endpoints and apolicy identifier identifying the rule governing traffic between thepair of endpoints; replacing the first plurality of whitelist policieswith a second plurality of whitelist policies, the second plurality ofwhitelist policies describing the same security rules for the sameendpoints as the first plurality of whitelist policies, using fewerwhitelist policies than the first plurality of whitelist policies, thereplacing based on populating a plurality of tables using the firstplurality of whitelist policies comprising: dividing the first pluralityof whitelist policies across a first table and a second table,comprising: including each pair of endpoints in the first plurality ofwhitelist policies in the first table and associating each pair ofendpoints with a respective service identifier in the first table; andincluding each respective service identifier in the second table, andassociating the service identifiers with the respective policyidentifiers for the first plurality of whitelist policies, wherein thefirst table does not include the policy identifiers and the second tabledoes not include the pairs of endpoints; programming the secondplurality of whitelist policies into a network device in thecommunication network, based on at least one of the plurality of tables;and enforcing the rules governing traffic between the pair of endpoints,at the network device, using the programmed second plurality ofwhitelist policies.
 2. The method of claim 1, wherein the network deviceis a network routing device and wherein the replacing the firstplurality of whitelist policies is performed on the network routingdevice.
 3. The method of claim 2, wherein the network routing device isa leaf switch.
 4. The method of claim 3, wherein the second plurality ofwhitelist policies are programmed into a memory associated with hardwareon the leaf switch, and wherein the hardware is used to enforce therules.
 5. The method of claim 1, wherein the network device comprises avirtual switch, wherein the second plurality of whitelist policies areprogrammed into a memory relating to the virtual switch, and whereinsoftware relating to the virtual switch is used to enforce the rules. 6.The method of claim 1, wherein the first plurality of whitelist policiesare generated automatically using an orchestration server for a datacenter.
 7. The method of claim 1, wherein populating the plurality oftables comprises: selecting a first whitelist policy of the firstplurality of whitelist policies; and determining that a first pair ofendpoints associated with the first whitelist policy is not included inthe first table, and in response adding an entry to the first tableincluding the first pair of endpoints and a first service identifier. 8.The method of claim 7, wherein populating the plurality of tablesfurther comprises: determining that a first policy identifier associatedwith the first whitelist policy is not included in a third table of theplurality of tables, and in response adding the first policy identifierto the third table; and adding an entry to a fourth table associatingthe first policy identifier with the first service identifier and thefirst pair of endpoints.
 9. The method of claim 8, wherein populatingthe plurality of tables further comprises: selecting a second whitelistpolicy of the first plurality of whitelist policies; determining thatthe second whitelist policy relates to the first pair of endpoints and asecond policy identifier; and in response updating the entry in thefourth table relating to the first pair of endpoints to associate thefirst pair of endpoints with both the first policy identifier and thesecond policy identifier.
 10. The method of claim 7, wherein populatingthe plurality of tables further comprises: selecting a second whitelistpolicy of the first plurality of whitelist policies, the secondwhitelist policy relating to a second pair of endpoints; and determiningthat the second pair of endpoints is included in the first table, and inresponse updating a second entry in the first table relating to thesecond pair of endpoints.
 11. A system, comprising: a hardwareprocessor; and a memory containing computer program code that, whenexecuted by the hardware processor, performs an operation comprising:identifying a first plurality of whitelist policies for a communicationnetwork, each whitelist policy describing a security rule governingtraffic between a pair of endpoints in the communication network andcomprising the pair of endpoints and a policy identifier identifying therule governing traffic between the pair of endpoints; replacing thefirst plurality of whitelist policies with a second plurality ofwhitelist policies, the second plurality of whitelist policiesdescribing the same security rules for the same endpoints as the firstplurality of whitelist policies, using fewer whitelist policies than thefirst plurality of whitelist policies, the replacing based on populatinga plurality of tables using the first plurality of whitelist policiescomprising: dividing the first plurality of whitelist policies across afirst table and a second table, comprising: including each pair ofendpoints in the first plurality of whitelist policies in the firsttable and associating each pair of endpoints with a respective serviceidentifier in the first table; and including each respective serviceidentifier in the second table, and associating the service identifierswith the respective policy identifiers for the first plurality ofwhitelist policies, wherein the first table does not include the policyidentifiers and the second table does not include the pairs ofendpoints; programming the second plurality of whitelist policies into anetwork device in the communication network, based on at least one ofthe plurality of tables; and enforcing the rules governing trafficbetween the pair of endpoints, at the network device, using theprogrammed second plurality of whitelist policies.
 12. The system ofclaim 11, wherein the network device is a network routing device andwherein the replacing the first plurality of whitelist policies isperformed on the network routing device.
 13. The system of claim 11,wherein the network device comprises a virtual switch, wherein thesecond plurality of whitelist policies are programmed into a memoryrelating to the virtual switch, and wherein software relating to thevirtual switch is used to enforce the rules.
 14. The system of claim 11,wherein the first plurality of whitelist policies are generatedautomatically using an orchestration server for a data center.
 15. Thesystem of claim 11, wherein populating the plurality of tablescomprises: selecting a first whitelist policy of the first plurality ofwhitelist policies; and determining that a first pair of endpointsassociated with the first whitelist policy is not included in the firsttable, and in response adding an entry to the first table including thefirst pair of endpoints and a first service identifier.
 16. The systemof claim 15, wherein populating the plurality of tables furthercomprises: selecting a second whitelist policy of the first plurality ofwhitelist policies, the second whitelist policy relating to a secondpair of endpoints; and determining that the second pair of endpoints isincluded in the first table, and in response updating a second entry inthe first table relating to the second pair of endpoints.
 17. Anon-transitory computer-readable medium containing computer program codethat, when executed by operation of one or more computer processors,performs an operation comprising: identifying a first plurality ofwhitelist policies for a communication network, each whitelist policydescribing a security rule governing traffic between a pair of endpointsin the communication network and comprising the pair of endpoints and apolicy identifier identifying the rule governing traffic between thepair of endpoints; replacing the first plurality of whitelist policieswith a second plurality of whitelist policies, the second plurality ofwhitelist policies describing the same security rules for the sameendpoints as the first plurality of whitelist policies, using fewerwhitelist policies than the first plurality of whitelist policies, thereplacing based on populating a plurality of tables using the firstplurality of whitelist policies comprising: dividing the first pluralityof whitelist policies across a first table and a second table,comprising: including each pair of endpoints in the first plurality ofwhitelist policies in the first table and associating each pair ofendpoints with a respective service identifier in the first table; andincluding each respective service identifier in the second table, andassociating the service identifiers with the respective policyidentifiers for the first plurality of whitelist policies, wherein thefirst table does not include the policy identifiers and the second tabledoes not include the pairs of endpoints; programming the secondplurality of whitelist policies into a network device in thecommunication network, based on at least one of the plurality of tables;and enforcing the rules governing traffic between the pair of endpoints,at the network device, using the programmed second plurality ofwhitelist policies.
 18. The computer-readable medium of claim 17,wherein the network device is a network routing device and wherein thereplacing the first plurality of whitelist policies is performed on thenetwork routing device.
 19. The computer-readable medium of claim 17,wherein the network device comprises a virtual switch, wherein thesecond plurality of whitelist policies are programmed into a memoryrelating to the virtual switch, and wherein software relating to thevirtual switch is used to enforce the rules.
 20. The computer-readablemedium of claim 17, wherein populating the plurality of tablescomprises: selecting a first whitelist policy of the first plurality ofwhitelist policies; determining that a first pair of endpointsassociated with the first whitelist policy is not included in the firsttable, and in response adding an entry to the first table including thefirst pair of endpoints and a first service identifier; selecting asecond whitelist policy of the first plurality of whitelist policies,the second whitelist policy relating to a second pair of endpoints; anddetermining that the second pair of endpoints is included in the firsttable, and in response updating a second entry in the first tablerelating to the second pair of endpoints.